inscatolati - Get out of the box! :)

If you are stracing a process and are getting an error like "strace: out of memory", watch out: this is not an error in the application, but an error in strace itself.

This message indicates that strace does not have enough memory to create its own structures to strace your process.

Certain versions of strace, still quite widespread as for year 2005/2006, have a bug in tracing multithreaded applications, which confuse strace about the memory it will need to strace the process.

To verify your application is multithreaded, you can use something like "ps -L aux". If your process as more than one line with the same PID, than it is multithreaded.

Updating strace might solve the problem. Another solution might be to start stracing your process before it spawns other threads. So, don't use the strace '-p' parameter, but strace the process since it starts.

Symptoms: customers accessing their own mailboxes report Outlook crashing or the connection being dropped, with a message similar to "Your server has unexpectedly terminated the connection...". You look into the user mailbox, and there doesn't seem to be anything strange. If you look carefully, you should see one or two really small mails.

It seems like Norton Antivirus causes Outlook to crash or the connection being dropped when a user receives a mail without body and no \n after the headers.

The problem has been reported to the CERT as a potential DoS, and Norton seems well aware of that problem. However, no fix is provided.

Two possible solutions:

• configure your mail server to always add a \n after the headers of any received email, even when there is no body.

• disable some Norton Antivirus options. Take a look at this issue on the Symantec Support site and to those instructions for more useful data. The links: Microsoft support and C4 Net support might also contain useful info.

Writing a client for the clamd daemon is usually a matter of a few lines of code: just connect to the daemon socket for each file you need to scan, issue the scanning command that best suit your needs, and that's it most of the times.

To avoid to open/close new connections with clamd continuosly, however, you can issue the SESSION clamd command, which allows a software to issue multiple commands on one, single, socket.

Beware, however, that clamd is able to recognize one, and only one command per packets it receives. If, after issueing the SESSION and STREAM command, for example, your client hangs, it's probably because the Linux Kernel joined the two different commands in one, single, packet.

The only solution we know about is to insert a sleep(1); between the write("SESSION"... and the write("STREAM"... command, hoping that a 1 second delay would be enough to avoid the nagle algorithm.

Note that we know no way to disable the nagle algorithm on Unix stream sockets, and afaik, there is no way to avoid the kernel joining the buffers but a small delay.

The problem is known to the clamav developers, but no solution has been proposed yet, mainly to avoid breaking compatibility with older clients.

If you are seeing this error when trying to access a web TLA archive, it probably means that the archive was created without the '-l' options to the make-archive command, or, for some reasons, no .listing files were created.

In this case, the only way to fix the archive is to ask the archive administrator, or someone with write permissions on the archive, to create the 'http-blows' file and to run a 'tla archive-fixup' command.

For more details, please take a look at http://notes.inscatolati.net/[en]/software[en]/tla[en]/index.html#7

Ever had an error like:

$ ./my-perl-script Can't locate ... in @INC (@INC contains: ...) at ... line ... . BEGIN failed--compilation aborted at ... line ... .

Well, this often happens when you have a directory with your perl scripts and its own modules, which you have not installed yet.

A good solution is usually to go in the lib/ directory of the tarball, or the directory containing the name of the missing module. For example, if the message above complains about missing RBC/XML.pm, with something like:

Can't locate RBC/XML.pm in @INC (@INC ...

You can simply:

$ find . -type d -name 'RBC' ./lib/RBC $ cd lib $ ../my-perl-script

Well, if you can't change directory, or you get another error about another missing library, you can simply use the PERL5LIB or PERLLIB environment variable, with something like:

$ PERL5LIB=/home/.../lib/ ./my-perl-script or $ export PERL5LIB=/home/.../lib/ $ ./my-perl-script

Note that if you use an absolute path in PERL5LIB, you can run my-perl-script from anywhere on your file system. Instead of PERL5LIB you can always use PERLLIB, or the -I parameter to the perl executable, with something like:

$ perl -I/home/.../lib/ ./my-perl-script

PERLLIB and PERL5LIB are ignored in case the script is somewhat privileged. To know more about all of this, just run:

$ man perlrun

and search '-I' or 'PERL5LIB'.

Ok, so... you are switching from a non-LVM system to using LVM... you have your /dev/sdb, and want to turn it in a Physical Volume to add to a simple Volume Group.

You try with a simple:

# pvcreate /dev/sdb

and you get an error:

Can't open /dev/sdb exclusively. Mounted filesystem?

you check the mount option, with something like:

mount |grep /dev/sdb

and nothing appears... (well, if something appears, just run umount all mounted partitions, and try one more time). So: pvcreate fails, reporting 'Mounted filesystems?', but no file systems are mounted.

The solution is quite simple: as long as the kernel sees partitions on the device, pvcreate will not be able to lock it to create a physical volume... (this is still true on a 2.6.16 with lvm2 2.02.05). So, remove the partitions (with cfdisk/sfdisk/fdisk, whatever you want, or dd if=/dev/zero of=/dev/sdb size=512 count=1) run 'sfdisk -R' and you should be fine... run pvcreate, and you will have no more errors...

# dd if=/dev/zero of=/dev/sdb size=512 count=1 # sfdisk -R # pvcreate /dev/sdb

At least twice in my life I've been surprised by grep either not matching what it was supposed to, or matching too much.

Both times it turned out to be a problem with the locale configured on the system. Yes, locale settings influence things like what are to be considered whitespaces, letters, and so on. grep and many other matching libraries keep that in consideration, and change behavior accordingly.

While this is kind of expected, if the locale configuration is screwed for the language being used, grep (and many other tools...) may really get confused.

Check the locale configurations, and try with things like:

LC_ALL=C grep ...

to see if the problem goes away or grep changes behavior. If it does change, well... you know for sure the problem is with the locales. Good luck with the debugging :)

On any linux systems, setlocale will fail unless you have the data for the selected locale compiled and available.

The symptoms range from:

• setlocale() returning NULL

• scripts returning errors like:

  perl: warning: Setting locale failed.

• web interfaces like imp, squirrel, or horde ignoring the language and the settings you selected

In Debian, to select the locales you want compiled and available, you need to use the command:

% dpkg-reconfigure -plow locales

This script will generate a file /etc/locale.gen listing all the locales that you are interested into. It will then call /usr/sbin/update-locale and /usr/sbin/locale-gen, which is the real script that takes care of compiling the locale files by running something like:

% localedef -i en_EN -c -f ISO-8859-15 -A /usr/share/locale/locale.alias en_EN

localedef, at least in Debian, will update the files in /usr/lib/locale/*